Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@src/main/java/com/kustacks/kuring/admin/adapter/in/web/AdminCommandApiV2.java`:
- Around line 145-147: Rename the multipart parameter to match the domain naming
to avoid missing poster uploads: change the `@RequestPart`(name = "postImage",
required = false) MultipartFile postImage parameter in AdminCommandApiV2 to use
"posterImage" (both the request part name and the local variable), and update
the call site that passes it into request.toCommand(iconImage, postImage) to
pass the new variable name instead (e.g., request.toCommand(iconImage,
posterImage)); ensure any other references in the same method or class are
updated accordingly.

In
`@src/main/java/com/kustacks/kuring/admin/adapter/out/event/ClubEventAdapter.java`:
- Around line 22-24: The poster image is being constructed with the wrong path:
in ClubEventAdapter when creating the ClubCreateImage for the poster you pass
iconImagePath instead of the poster's path variable; update the
ClubCreateImage(...) call used to build "poster" so it uses the poster image
path (the correct posterImagePath/variable) while keeping the same posterImage
content, then raise the ClubCreateEvent(clubId, icon, poster) unchanged.
- Around line 29-30: In the catch(IOException e) inside ClubEventAdapter (the
block that currently throws new
InvalidStateException(ErrorCode.FILE_IO_EXCEPTION)), preserve the original
exception by passing it as the cause to the InvalidStateException (or calling
initCause) so the IOException stacktrace is retained; update the
InvalidStateException construction to accept the cause (or add an appropriate
constructor) and include e when rethrowing alongside
ErrorCode.FILE_IO_EXCEPTION.

In
`@src/main/java/com/kustacks/kuring/club/application/port/in/ClubCreateAdminUseCase.java`:
- Around line 5-6: The use-case interface ClubCreateAdminUseCase currently
declares void createClub(AdminClubCreateCommand) so the created entity ID from
ClubCommandService.createClub (where savedClub is obtained) cannot be returned
to the controller; change the interface method signature to return either Long
or AdminClubCreateResponse (e.g., Long createClub(... ) or
AdminClubCreateResponse createClub(...)), update the implementing method
ClubCommandService.createClub to return the savedClub.getId() or build and
return an AdminClubCreateResponse, and propagate that return value back to the
controller so it passes the real clubId instead of null.

In
`@src/main/java/com/kustacks/kuring/club/application/port/in/dto/AdminClubCreateCommand.java`:
- Line 11: Change the nullable wrapper type for the isAlways field in
AdminClubCreateCommand from Boolean to the primitive boolean to enforce
non-nullability at the application layer; update the declaration and any
constructor/record component, accessors or usages within AdminClubCreateCommand
(and any places that construct it) to use primitive boolean, relying on the
`@NotNull` validation performed in AdminClubCreateRequest to guarantee a value.

In
`@src/main/java/com/kustacks/kuring/club/application/port/out/ClubCommandPort.java`:
- Around line 8-12: The interface ClubCommandPort is missing the
existsByNameAndDivision method used by ClubPersistenceAdapter; add a declaration
boolean existsByNameAndDivision(String name, ClubDivision division) to
ClubCommandPort (and import ClubDivision) so the persistence adapter can
implement it consistently alongside save(Club) and saveAll(List<ClubSns>);
alternatively, if you prefer separation of command vs query responsibilities,
move that method to a new or existing query port and update
ClubPersistenceAdapter to implement the appropriate port.

In
`@src/main/java/com/kustacks/kuring/club/application/service/ClubCommandService.java`:
- Around line 139-142: 추가 동시성 안전장치가 필요합니다: 엔티티의 (name, division) 컬럼에 DB 유니크 제약을
추가하고, 애플리케이션 레벨의 validateDuplicateClub(AdminClubCreateCommand, ClubDivision) 체크는
유지하되 저장 시 발생하는 제약 위반을 예외로 변환하도록 예외 처리를 추가하세요—즉 Club 엔티티에 복합 유니크 인덱스(또는 DDL 제약)를
선언하고, 실제 저장 호출을 수행하는 코드(예: ClubCommandService의 저장 메서드 또는
clubRepository.save/clubCommandPort.save 호출부)에서 DataIntegrityViolationException
같은 DB 제약 위반 예외를 잡아 InvalidStateException(CLUB_DUPLICATED)로 재던지도록 구현합니다.

In `@src/main/java/com/kustacks/kuring/club/domain/ClubSnsType.java`:
- Around line 17-23: fromUrl currently uses startsWith on the whole URL causing
false positives (e.g. "youtube" in malicious domains); change
ClubSnsType.fromUrl to parse the host via new URL(url).getHost() (handle
MalformedURLException by returning ETC) and compare that host against each
clubSnsType.urls entry using exact match or suffix match with a dot prefix (e.g.
host.equalsIgnoreCase(pattern) || host.endsWith("."+pattern)) instead of
startsWith; update the filtering lambda that currently references
clubSnsType.urls.stream().anyMatch(url::startsWith) to use the parsed host and
the safer equality/suffix checks.

In
`@src/main/java/com/kustacks/kuring/storage/adapter/in/event/dto/ImageDeleteEvent.java`:
- Around line 1-6: ImageDeleteEvent is currently unused; either remove the
record ImageDeleteEvent(String fileName) from the PR if not needed now, or if
you intend it for future work, add a clear comment/Javadoc above the
ImageDeleteEvent record explaining its intended future use and lifecycle and
optionally annotate/suppress unused warnings so static analysis doesn't flag it;
update the commit accordingly and ensure no imports/reference remain broken when
removing or annotating ImageDeleteEvent.

In
`@src/main/java/com/kustacks/kuring/storage/application/port/in/dto/UploadSingleImageCommand.java`:
- Line 6: The incomplete inline comment on the byte[] fileBytes parameter in
UploadSingleImageCommand is unclear; either remove the “// 아래 내용들을.” comment or
replace it with a concise, meaningful description of the parameter’s purpose
(e.g., "file bytes of the uploaded image" or "raw image data") to improve
readability and maintainability; update the JavaDoc or inline comment near the
UploadSingleImageCommand constructor/field to reflect the chosen wording.
- Line 6: Remove the leftover inline comment "// 아래 내용들을." from the record
component declaration in UploadSingleImageCommand and add a compact constructor
that makes a defensive copy of the byte[] fileBytes (e.g., allocate new
byte[fileBytes.length] and System.arraycopy) and assign the copy to
this.fileBytes (or validate null and copy accordingly) so external mutations
cannot affect the record's internal array; keep the rest of the record
unchanged.

---

Outside diff comments:
In `@src/test/java/com/kustacks/kuring/club/domain/ClubCategoryTest.java`:
- Around line 19-25: Rename the misnamed test method fromKorNameName to reflect
what's being tested: e.g., fromName (or fromEnglishName); update the test method
name that calls ClubCategory.fromName(name) and asserts equality with the
expected ClubCategory so the method name matches the tested function
ClubCategory.fromName and the English test data (academic, culture_art, etc.).
- Around line 29-39: The test method name has a typo "fromKorNameNameException"
causing a naming mismatch; rename the test method to a clear, consistent name
(e.g., "fromKorNameException" or "fromNameException") so it matches the other
tests, and keep the test body unchanged — locate the method in ClubCategoryTest
and update the method declaration name that wraps the ThrowingCallable calling
ClubCategory.fromName(name).

In `@src/test/java/com/kustacks/kuring/club/domain/ClubDivisionTest.java`:
- Around line 19-25: The test method name fromKorNameName does not match the
exercised method; update the test to match intent: either rename the test method
fromKorNameName to a descriptive name like fromNameTest (or
fromName_whenValidName_returnsDivision) to reflect that it calls
ClubDivision.fromName(name), or change the test body to call
ClubDivision.fromKorName(name) and adjust test data accordingly; locate the
method in class ClubDivisionTest and update the method name or the invoked
static method (ClubDivision.fromName vs ClubDivision.fromKorName) so name and
behavior are consistent.
- Around line 29-39: Test method name fromKorNameNameException mismatches the
behavior: it calls ClubDivision.fromName(name) but the name implies a "Kor"
variant; rename the test to reflect what's being tested (e.g., fromNameException
or fromNameThrowsNotFoundException) or change the call to
ClubDivision.fromKorName(name) to match the existing name; update the test
method name (fromKorNameNameException) or the invoked method
(ClubDivision.fromName(name)) so the test name and tested symbol align.

---

Nitpick comments:
In
`@src/main/java/com/kustacks/kuring/club/application/port/out/ClubEventPort.java`:
- Around line 5-7: The ClubEventPort interface currently depends on Spring's
MultipartFile via the method publishClubCreate in ClubEventPort; replace the
MultipartFile parameters with framework-agnostic types (e.g., byte[] or
InputStream) to decouple the port from Spring, update all
implementations/adapters that implement publishClubCreate to accept and
propagate the new types, and ensure any callers (controllers/adapters) convert
MultipartFile to the chosen byte[]/InputStream while handling stream lifecycle
and buffering concerns so input streams are consumed/closed before leaving the
adapter layer.

In
`@src/main/java/com/kustacks/kuring/club/application/service/ClubCommandService.java`:
- Around line 184-233: The image upload currently only checks emptiness and
filename extension (validateRequiredIconImage, extractExtension,
generateFileName) which allows non-image files; add actual image type validation
by reading the uploaded MultipartFile content (e.g., using ImageIO or checking
magic bytes) to confirm it decodes as a supported image format
(jpg/jpeg/png/gif) and determine the canonical extension; if decoding fails or
the detected format is not allowed, throw
InvalidStateException(API_INVALID_PARAM). Also update generateFileName to use
the detected canonical extension instead of the raw filename extension so stored
filenames reflect the real image type.

In
`@src/main/java/com/kustacks/kuring/storage/adapter/in/event/dto/ClubCreateEvent.java`:
- Around line 25-38: ClubCreateImage currently stores an InputStream
(pathAndName, inputstream, contentType, size) which breaks record immutability
and risks double-consumption/ leaking; change ClubCreateImage to capture the
file contents as an immutable byte[] (or store the MultipartFile) instead of an
InputStream, read and close file.getInputStream() inside the ClubCreateImage
constructor, and update toUploadFile() to return UploadFileCommand.UploadFile
with a fresh ByteArrayInputStream(new byte[]) so consumers can safely read/close
independently; also audit usages of ClubCreateImage and listeners to ensure the
stream is consumed exactly once by converting any direct InputStream consumers
to use toUploadFile() which provides a fresh stream.

In
`@src/main/java/com/kustacks/kuring/storage/adapter/in/event/StorageEventListener.java`:
- Line 11: 클래스에 붙은 사용되지 않는 `@Slf4j` 어노테이션을 정리하세요: StorageEventListener 클래스에서 로깅을
전혀 사용하지 않으면 `@Slf4j` 주석을 제거하고 불필요한 import를 삭제하거나, 이벤트 수신을 기록하려면
onApplicationEvent(또는 해당 이벤트 핸들러 메서드) 안에 수신 시점과 주요 페이로드(예: 이벤트 타입, id 등)를 기록하는
log.debug/info 호출을 추가해 주세요; 결정한 방식에 따라 `@Slf4j` 유지 시 log를 실제로 사용하거나, 사용하지 않으면
어노테이션과 lombok.slf4j.Slf4j import를 제거하십시오.

In
`@src/main/java/com/kustacks/kuring/storage/application/port/in/dto/UploadFileCommand.java`:
- Around line 9-14: Remove the incomplete inline comment "// 아래 내용들을." from the
UploadFile record declaration and either replace it with a brief, meaningful
comment (e.g. noting that InputStream must be closed by the caller) or remove
the comment entirely; also add a short note in the Javadoc or comment for the
UploadFile record that InputStream lifecycle is the caller's responsibility and
callers (including StorageCommandService.upload()) must close the stream (e.g.
via try-with-resources) to avoid leaks, referencing the UploadFile record and
StorageCommandService.upload() so reviewers can verify all usages close the
stream.

In
`@src/main/java/com/kustacks/kuring/storage/application/StorageCommandService.java`:
- Around line 29-43: The upload method in StorageCommandService currently
swallows failures and only logs them, so callers cannot know which files
succeeded or failed; change upload(UploadFileCommand.UploadFile file) to return
a result object (e.g., UploadResult with fields success:boolean, key:String,
error:String) or at minimum a boolean, populate it from the try/catch around
storagePort.upload, and propagate that result up to the caller so callers can
track successful vs failed files; alternatively (or additionally) emit a metric
or increment a failure counter (e.g., via MeterRegistry) inside the catch blocks
including file.key() and e.getMessage() to expose failures to monitoring.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In
`@src/main/java/com/kustacks/kuring/admin/adapter/out/event/ClubEventAdapter.java`:
- Around line 29-30: The IOException caught in ClubEventAdapter should be
propagated as the cause when throwing InvalidStateException so the original
stacktrace isn't lost; update the catch block that currently does "throw new
InvalidStateException(ErrorCode.FILE_IO_EXCEPTION);" to pass the caught
exception (e) as the cause via InvalidStateException's constructor or initCause
(e.g., new InvalidStateException(ErrorCode.FILE_IO_EXCEPTION, e)), ensuring
InvalidStateException's constructor supports a Throwable cause or add one if
needed.

---

Nitpick comments:
In
`@src/main/java/com/kustacks/kuring/admin/adapter/out/event/ClubEventAdapter.java`:
- Around line 22-27: posterImage 분기에 따라 Events.raise(...) 호출이 중복되어 있으니 먼저
posterImage를 기반으로 ClubCreateImage poster 변수를 계산(포스터가 없으면 null)하고 그 후 한 번만
Events.raise(new ClubCreateEvent(clubId, icon, poster))를 호출하도록 변경하세요; 관련 식별자:
posterImage, posterImagePath, ClubCreateImage, poster, Events.raise,
ClubCreateEvent, clubId, icon.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/main/java/com/kustacks/kuring/club/domain/ClubSnsType.java`:
- Around line 40-47: The extractHost(String url) method can NPE on url.trim()
when callers pass null (e.g., fromUrl(null)); add a null/blank guard at the
start of extractHost to validate the incoming url (check for null or empty after
trimming) and throw the same InvalidStateException(ErrorCode.API_INVALID_PARAM)
for invalid input; then proceed to URI.create(url.trim()) and return
uri.getHost() as before.

---

Nitpick comments:
In `@src/test/java/com/kustacks/kuring/club/domain/ClubSnsTypeTest.java`:
- Around line 37-49: The test suite is missing coverage for the code path that
throws InvalidStateException in ClubSnsType.fromUrl; add a unit test that
invokes ClubSnsType.fromUrl with a URL that causes URI.create() to throw and
assert that InvalidStateException is thrown (e.g., a clearly malformed URI),
using assertThatThrownBy to verify the exception type; update imports to include
static org.assertj.core.api.Assertions.assertThatThrownBy and
com.kustacks.kuring.common.exception.InvalidStateException and add the new test
method (or parameterized case) alongside fromUrl_withInvalidOrUnsupported to
validate the exception path.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@src/main/java/com/kustacks/kuring/club/domain/ClubSnsType.java`:
- Around line 35-46: The current ClubSnsType.fromUrl / extractHost flow can
silently treat invalid or relative URLs (and uppercase hosts) as ETC because
URI.create(url).getHost() can return null; update extractHost(String url) to:
trim input, attempt to ensure a scheme (e.g., if url does not start with a
scheme, prepend "https://") before creating the URI, check uri.getHost() for
null and if null throw InvalidStateException(ErrorCode.API_INVALID_PARAM)
instead of returning null, and normalize the returned host to lowercase before
returning so HOST_TO_TYPE lookup is case-insensitive; keep the caller (fromUrl)
using HOST_TO_TYPE.getOrDefault(host, ETC) after these validations.